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Definicion de Mantenibilidad 


El IEEE| footnote] (19990) define mantenibilidad como: “La facilidad con 
la que un sistema 0 componente software puede ser modificado para 
corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a 
cambios en el entorno”. 

Institute of Electrical and Electronics Engineers. (1990) IEEE Standard 
Computer Dictionary: A Compilation of IEEE Standard Computer 
Glossaries. New York, NY.IEEE Std. 610.12 (1990) Standard Glossary of 
Software Engineering Terminology. IEEE Computer Society Press, Los 
Alamitos, CA. 


Esta definicién esta directamente conectada con la definicion del IEEE para 
mantenimiento del software: “es el proceso de modificar un componente o 
sistema software después de su entrega para corregir fallos, mejorar su 
funcionamiento u otros atributos o adaptarlo a cambios en el entorno”. 


En consecuencia, la mantenibilidad es una caracteristica de calidad del 
software relacionada con la facilidad de mantenimiento, que nosotros 
consideraremos como una actividad de mantenimiento. 


A mayor mantenibilidad, menores costes de mantenimiento (y viceversa). 


La mantenibilidad debe establecerse como objetivo tanto en las fases 
iniciales del ciclo de vida, para reducir las posteriores necesidades de 
mantenimiento, como durante las fases de mantenimiento, para reducir los 
efectos laterales y otros inconvenientes ocultos (y seguir asi reduciendo las 
futuras necesidades de mantenimiento). 


La calidad del software es una compleja mezcla de factores que variaran a 
través de diferentes aplicaciones y segtn los clientes que las pidan. Dichos 
factores se pueden dividir en 2 grupos: 


e factores que se pueden medir directamente 
e factores que se pueden medir solo indirectamente. 


McCall[footnote] propuso una util clasificacién de factores que afectan a la 
calidad del software. Estos factores son: 


Roger S. Presuman (2002) Ingenieria del Software. Un enfoque practico 


e Correccién — Hasta dénde satisface un programa su especificacion y 
logra los objetivos propuestos por el cliente. 

e Fiabilidad — Hasta donde se puede esperar que un programa lleve a 
cabo su funcién con la exactitud requerida. 

e Eficiencia — La cantidad de recursos informaticos y de cddigos 
necesarios para que un programa realice su funcion. 

e Integridad — Hasta donde se puede controlar el acceso al software 0 a 
los datos por personas no autorizadas. 

e Usabilidad > El esfuerzo necesario para aprender a operar con el 
sistema, preparar los datos de entrada e interpretar las salidas 
(resultados) de un programa. 

e Facilidad de mantenimiento (mantenibilidad) > El esfuerzo necesario 
para localizar y arreglar un error en un programa. 

e Flexibilidad — El esfuerzo necesario para modificar un programa que 
ya esta en funcionamiento. 

e Facilidad de prueba > El esfuerzo necesario para probar un programa 
y asegurarse de que realiza correctamente su funcion. 

e Portabilidad > El esfuerzo necesario para transferir el programa de un 
entorno hardware/software a otro entorno diferente. 

e Reusabilidad — Hasta donde se puede volver a emplear un programa 
en otras aplicaciones, en relacidn al empaquetamiento y alcance de las 
funciones que realiza el programa. 

e Interoperatividad — El esfuerzo necesario para acoplar un sistema con 
otro. 


Hewlett-Packard ha desarrollado un conjunto de factores de calidad del 
software al que se le ha dado el acr6nimo de FURPS (Funcionality, 
Usability, Reliability, Reformance, Supportability). Los atributos 
contemplados en cada uno de estos cinco factores son: 


e Funcionalidad > Se valora evaluando el conjunto de caracteristicas y 
capacidades del programa, la generalidad de las funciones entradas y la 
seguridad del sistema global. 

e Usabilidad > Se valora evaluando el conjunto de caracteristicas y 
capacidades del programa, la generalidad de las funciones entregadas y 


la seguridad del sistema global. 

e Fiabilidad — Se evaltia midiendo la frecuencia y gravedad de los 
fallos, la exactitud de las salidas, el tiempo medio de fallos, la 
capacidad de recuperacion de un fallo y la capacidad de prediccion del 
programa. 

e Rendimiento — Se mide por la velocidad del procesamiento, el tiempo 
de respuesta, consumo de recursos, rendimiento efectivo total y 
eficacia. 

e¢ Capacidad de Soporte - Combina la capacidad de ampliar el 
programa, adaptabilidad y servicios, asi como la capacidad para hacer 
pruebas, compatibilidad, capacidad de configuracion del software, la 
facilidad de instalacion de un sistema y la facilidad con que se pueden 
localizar los programas. 


Los factores de calidad FURPS y atributos descritos pueden usarse para 
establecer métricas de la calidad para todas las actividades del proceso del 
software 


Aspectos que influyen en la Mantenibilidad 


El IEEE| footnote] (19990) define mantenibilidad como: “La facilidad con 
la que un sistema o componente software puede ser modificado para 
corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a 
cambios en el entorno”. 

Institute of Electrical and Electronics Engineers. (1990) IEEE Standard 
Computer Dictionary: A Compilation of IEEE Standard Computer 
Glossaries. New York, NY.IEEE Std. 610.12 (1990) Standard Glossary of 
Software Engineering Terminology. IEEE Computer Society Press, Los 
Alamitos, CA. 


Esta definicién esta directamente conectada con la definicion del IEEE para 
mantenimiento del software: “es el proceso de modificar un componente o 
sistema software después de su entrega para corregir fallos, mejorar su 
funcionamiento u otros atributos o adaptarlo a cambios en el entorno”. 


En consecuencia, la mantenibilidad es una caracteristica de calidad del 
software relacionada con la facilidad de mantenimiento, que nosotros 
consideraremos como una actividad de mantenimiento. 


A mayor mantenibilidad, menores costes de mantenimiento (y viceversa). 


La mantenibilidad debe establecerse como objetivo tanto en las fases 
iniciales del ciclo de vida, para reducir las posteriores necesidades de 
mantenimiento, como durante las fases de mantenimiento, para reducir los 
efectos laterales y otros inconvenientes ocultos (y seguir asi reduciendo las 
futuras necesidades de mantenimiento). 


Existen unos pocos factores que afectan directamente a la mantenibilidad, 
de forma que si alguno de ellos no se satisface adecuadamente, ésta se 
resiente. Los tres mas significativos son: 


¢ Proceso de desarrollo: la mantenibilidad debe formar parte integral del 
proceso de desarrollo del software. Las técnicas utilizadas deben ser lo 
menos intrusivas posible con el software existente. Los problemas que 
surgen en muchas organizaciones de mantenimiento son de doble 
naturaleza: mejorar la mantenibilidad y convencer a los responsables 


de que la mayor ganancia se obtendra inicamente cuando la 
mantenibilidad esté incorporada intrinsecamente en los productos 
software. 

e Documentacion: En multiples ocasiones, ni la documentacion ni las 
especificaciones de disefio estan disponibles, y por tanto, los costes del 
mantenimiento se incrementan debido al tiempo requerido para que un 
mantenedor entienda el disefo del software antes de poder ponerse a 
modificarlo. Las decisiones sobre la documentacién que debe 
desarrollarse son muy importantes cuando la responsabilidad del 
mantenimiento de un sistema se va a transferir a una organizacion 
nueva. 

¢ Comprension de Programas: La causa basica de la mayor parte de los 
altos costes del MS es la presencia de obstaculos a la comprension 
humana de los programas y sistemas existentes. Estos obstaculos 
surgen de tres fuentes principales: 


o La informacion disponible es incomprensible, incorrecta o 
insuficiente. 

o La complejidad del software, de la naturaleza de la aplicacién o 
de ambos. 

o La confusion, mala interpretacion o olvidos sobre el programa o 
sistema. 


Dependiendo de como se haya construido el software se puede aumentar la 
mantenibilidad. Los generadores de cédigo, por lo general, no producen un 
cédigo claro ni facil de comprender, por lo que el mantenimiento del 
software asi generado es peor. Por otro lado, las técnicas de programacion 
estructurada, la aplicacion de metodologias de ingenieria del software y el 
seguimiento de estandares, permiten la obtencién de sistemas o 
componentes software con menos necesidades de mantenimiento, y en el 
caso de que se produzcan, mucho mas faciles de llevar a cabo. 


Mas concretamente, se han identificado los factores especificos que 
influyen en la mantenibilidad: 


e Falta de cuidado en las fases de diseno, codificaci6n o prueba. 
e Pobre configuracion del producto software. 
e Adecuada cualificacién del equipo de desarrolladores del software. 


Estructura del software facil de comprender. 

Facilidad de uso del sistema. 

Empleo de lenguajes de programacion y sistemas operativos 
estandarizados. 

Estructura estandarizada de la documentacion. 

Documentacion disponible de los casos de prueba. 

Incorporacion en el sistema de facilidades de depuracion. 
Disponibilidad del equipo (computador y periféricos) adecuado para 
realizar el mantenimiento. 

Disponibilidad de la persona o grupo que desarrollo originalmente el 
software. 

Planificacion del mantenimiento. 


Propiedades de la Mantenibilidad 


El IEEE| footnote] (19990) define mantenibilidad como: “La facilidad con 
la que un sistema o componente software puede ser modificado para 
corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a 
cambios en el entorno”. 

Institute of Electrical and Electronics Engineers. (1990) IEEE Standard 
Computer Dictionary: A Compilation of IEEE Standard Computer 
Glossaries. New York, NY.IEEE Std. 610.12 (1990) Standard Glossary of 
Software Engineering Terminology. IEEE Computer Society Press, Los 
Alamitos, CA. 


La mantenibilidad se puede considerar como la combinacion de dos 
propiedades diferentes: La reparabilidad y la flexibilidad. 


Reparabilidad 


Un sistema software es reparable si permite la correcci6n de sus defectos 
con una cantidad de trabajo limitada y razonable. 


La reparabilidad se ve afectada por la cantidad y tamanio de los 
componentes o piezas. Un producto software que consiste en mddulos bien 
disenados es mas facil de analizar y reparar que uno monolitico, pero el 
incremento del numero de médulos no implica un producto mas reparable, 
ya que también aumenta la complejidad de las interconexiones entre 
mddulos. 


Asi pues, se debe buscar un punto de equilibrio con la estructura de 
modulos mas adecuada para garantizar la reparabilidad facilitando la 
localizacion y eliminacion de los errores en unos pocos modulos. 


Un software por mucho que se use no Sse gasta. Ya le podemos dar veces al 


boton de aceptar, que, en principio, no deberia desgastarse y dejar de 
funcionar sin motivo aparente. 


Flexibilidad 


Un sistema software es flexible si permite cambios para que se satisfagan 
nuevos requerimientos, es decir, si puede evolucionar. Por su naturaleza 
inmaterial, es software es mucho mas facil de cambiar o incrementar por lo 
que respecta a sus funciones que otros productos de naturaleza fisica, por 
ejemplo, equipos hardware, pero esta flexibilidad se ve disminuida con cada 
nueva version de un producto software, ya que cada version complica la 
estructura del software y, por tanto, las futuras modificaciones seran mas 
dificiles. 


Aunque esto puede considerarse una generalidad, la aplicacion de técnicas y 
metodologias apropiadas pueden minimizar el impacto en la flexibilidad de 
cada nueva modificacién en el software. Es por esto que la flexibilidad es 
una caracteristica tanto del producto software como de los procesos 
relacionados con su construccion. En términos de estos ultimos, los 
procesos deben poderse acomodar a nuevas técnicas de gestion y 
organizacion, a cambios en la forma de entender la ingenieria, etc. 


Estandar ISO 9126 del IEEE y la Mantenibilidad 


ISO 9126 es un estandar internacional para la evaluacion del Software. Esta 
supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los 
mismos conceptos. 


El estandar esta dividido en cuatro partes las cuales dirigen, 
respectivamente, lo siguiente: modelo de calidad, métricas externas, 
métricas internas y calidad en las métricas de uso. 


El modelo de calidad establecido en la primera parte del estandar, ISO 
9126-1. Dicho estandar ha sido desarrollado en un intento de identificar los 
atributos clave de calidad para el software. El estandar identifica 6 atributos 
clave de calidad: 


¢ Funcionalidad — El grado en que el software satisface las necesidades 
indicadas por los siguientes subatributos: 


Idoneidad 
Correccion 
Interoperabilidad 
Conformidad 
Seguridad 


oOo 0 0 0 


e Fiabilidad — Cantidad de tiempo que el software esta disponible para 
su uso. Esta referido por los siguientes subatributos: 


o Madurez 
o Tolerancia a fallos 
o Facilidad de recuperacion 


e Usabilidad — Grado en que el software hace optimo el uso de los 
recursos del sistema. Esta indicado por los siguientes subatributos: 


© Facilidad de comprension 
© Facilidad de aprendizaje 
o Operatividad 


e Eficiencia — Grado en que el software hace 6ptimo el uso de los 
recursos del sistema. Esta indicado por los siguientes subatributos: 


o Tiempo de uso 
o Recursos utilizados 


e Mantenibilidad — Facilidad con que una modificaci6n puede ser 
realizada. Esta indicada por los siguientes subatributos: 


o Facilidad de analisis 
o Facilidad de cambio 
o Estabilidad 

© Facilidad de prueba 


e Portabilidad — La facilidad con que el software puede ser Ilevado de un 
entorno a otro. Esta referido por los siguientes subatributos: 


o Facilidad de instalaci6n 
© Facilidad de ajuste 
o Facilidad de adaptacion al cambio 


E] atributo Conformidad no esta listada arriba ya que se aplica a todas las 
caracteristicas. Ejemplos son conformidad a la legislacion referente a 
usabilidad y fiabilidad. 


Un atributo es una entidad la cual puede ser verificada 0 medida en el 
producto software. Los atributos no estan definidos en el estandar, ya que 
varian entre diferentes productos software. 


Un producto software esta definido en un sentido amplio como: los 
ejecutables, codigo fuente, descripciones de arquitectura, y asi. Como 
resultado, la nocién de usuario se amplia tanto a operadores como a 
programadores, los cuales son usuarios de componentes como son 
bibliotecas software. 


El estandar provee un entorno para que las organizaciones definan un 
modelo de calidad para el producto software. Haciendo esto asi, sin 
embargo, se lleva a cada organizacion la tarea de especificar precisamente 


su propio modelo. Esto podria ser hecho, por ejemplo, especificando los 
objetivos para las métricas de calidad las cuales evaluan el grado de 
presencia de los atributos de calidad. 


Métricas internas son aquellas que no dependen de la ejecucion del software 
(medidas estaticas). 


Métricas externas son aquellas aplicables al software en ejecucion. 


La calidad en las métricas de uso estan solo disponibles cuando el producto 
final es usado en condiciones reales. 


Idealmente, la calidad interna determina la calidad externa y esta a su vez la 
calidad en el uso. 


Este estandar proviene desde el modelo establecido en 1977 por McCall y 
sus colegas, los cuales propusieron un modelo para especificar la calidad 
del software. El modelo de calidad McCall esta organizado sobre tres tipos 
de Caracteristicas de Calidad: 


e Factores (especificar): Ellos describen la visidn externa del software, 
como es visto por los usuarios. 

e Criterios (construir): Ellos describen la vision interna del software, con 
es visto por el desarrollador. 

e Métricas (controlar): Ellas son definidas y usadas para proveer una 
escala y método para la medida. 


ISO 9126 distingue entre fallos y no conformidad, siendo un fallo el no 
cumplimiento de los requisitos previos, mientras que la no conformidad 
afecta a los requisitos especificados. Una distincién similar es hecha entre 
la validacion y la verificaci6n. 


Utilidad de las normas ISO / IEC 9126 


Este estandar esta pensado para los desarrolladores, adquirentes, personal 
que asegure la calidad y evaluadores independientes, responsables de 
especificar y evaluar la calidad del producto software. 


Por tanto, puede servir para validar la completitud de una definicion de 
requisitos, identificar requisitos de calidad de software, objetivos de disefo 
y prueba, criterios de aseguramiento de la calidad, etc. 


La calidad de cualquier proceso del ciclo de vida del software (estandar ISO 
12.207) influye en la calidad del producto software que, a su vez, 
contribuye a mejorar la calidad en el uso del producto. 


La calidad del software puede evaluarse midiendo los atributos internos 
(medidas estaticas 0 productos intermedios) o atributos externos 
(comportamiento del codigo cuando se ejecuta). 


Métricas de Mantenibilidad del Software 


Se han propuesto cientos de métricas para el software, pero no todas 
proporcionan un soporte practico para el desarrollador de software. Algunas 
demandan mediciones que son demasiado complejas, otras son tan 
esotéricas que pocos profesionales tienen la esperanza de entenderlas y 
otras violan las nociones basicas intuitivas de lo que realmente es el 
software de alta calidad. 


Existen una serie de caracteristicas que deberian acompafiar a las métricas 
efectivas del software. Dichas caracteristicas son: 


e Simples y faciles de calcular 

e Empirica e intuitivamente persuasivas 

e Consistentes y objetivas 

e Consistentes en el empleo de unidades y tamafio 

e Independientes del lenguaje de programacion 

e Eficaz mecanismo para la realimentacion de calidad 


Aunque la mayoria de las métricas de software satisfacen las caracteristicas 
anteriores, algunas de las métricas comunmente empleadas dejan de 
cumplir una o dos. 


Las métricas de mantenibilidad no pueden medir el coste de realizar un 
cambio particular al sistema software, sino que miden aspectos de la 
complejidad y la calidad de los programas ya que existe una alta correlacion 
entre la complejidad y la mantenibilidad (a mayor complejidad menor 
mantenibilidad) y entre la calidad y la mantenibilidad (a mayor calidad 
mayor mantenibilidad — y viceversa — ). 


Existen maneras de medir la mantenibilidad para todos los elementos 
software que estan o estaran sometidos a mantenimiento: cddigo, 
documentos de usuario, documentos de analisis o diseno, etc. 


Las métricas del software se pueden clasificar en tres categorias 
(Kan[footnote], 2002): 

Kan, S. (2002) Software Quality Metrics Overview. En Metrics and Models 
in Software Quality Engineering, 2nd Edition. Addison Wesley Professional 


1. Métricas de producto. Estas métricas describen las caracteristicas del 
producto que de alguna forma determinan la mantenibilidad, por 
ejemplo el tamafio, complejidad o caracteristicas del disefo. 

2. Métricas del proceso. Las métricas del proceso pueden ser utilizadas 
para mejorar el desarrollo y mantenibilidad del software. Algunos 
ejemplos incluyen la eficacia de eliminar defectos durante el 
desarrollo, el patron en el que aparecen los defectos durante las 
pruebas o el tiempo fijo de respuesta del proceso. 

3. Métricas de proyecto. Las métricas de proyecto describen las 
caracteristicas y ejecucion del proyecto. Por ejemplo, el numero de 
desarrolladores, el patron de staffing en el ciclo de vida, coste, 
planificaci6n y productividad del software. 


Ademas, algunas métricas pueden pertenecer a multiples categorias. 


Métricas de Mantenibilidad Orientadas al Producto 


Estas métricas describen las caracteristicas del producto que de alguna 
forma determinan la mantenibilidad, por ejemplo el tamano, complejidad o 
caracteristicas del diseno. 


Las 4 métricas orientadas al producto son: 


La densidad de comentarios en el codigo 

e Métricas de Complejidad. 

e El indice de madurez del software (IMS) 

e Métricas en Orientaci6n a Objetos: Chidamber & Kemerer 


Densidad de comentarios en el codigo 


Aunque no existen muchas métricas conocidas a este respecto, es 
significativo para el mantenimiento de un sistema o componente software lo 
bien documentado que se encuentre. Obviamente, cuantos mas comentarios 
haya en el codigo fuente, mayor mantenibilidad tendra el software. 


Para observar la densidad de comentarios que hay en el codigo hay que 
realizar una inspeccion del cddigo fuente. Si el codigo fuente esta realizado 
en Java, una medida facilmente obtenible es la estudia la proporcion de 
javadocs por numero de lineas de cddigo significativas, es decir, lineas de 
codigo que contengan sentencias que no sean de comienzo o fin (llaves, en 
el caso de Java) ni comentarios: 


LOCS 


Densidad comentarios = Se 
n° Javadocs 


Cuanto mayor sea la densidad de comentarios, mas mantenible sera el 
software examinado. 


Métricas de Complejidad 


Son todas las métricas de software que definen de una u otra forma la 
medicion de la complejidad; Tales como volumen, tamafio, anidaciones, 


costo (estimacion), agregacion, configuracion, y flujo. Estas son los puntos 
criticos de la concepcion, viabilidad, andalisis, y disefio de software. 


Los 2 tipos de métrica para calcular la complejidad es: 


¢ Complejidad ciclomatica de McCabe] footnote] 

McCabe,T.J., y A.H. Watson, “Solftware Complexity”, Crosstalk. 
e Ciencia del Software de Halstead[footnote] 

Halstead, M., “Elements of Software Science”, Holland. 


Indice de Madurez del Software (IMS) 


El estandar del IEEE 982.1-1988 sugiere un indice de madurez del software 
(IMS) como métrica especifica de mantenimiento. Esta métrica proporciona 
una indicacion de la estabilidad de un producto software. A medida que el 
IMS se aproxima a 1, el producto comienza a estabilizarse, y por lo tanto, 
menos esfuerzo de mantenimiento requerira. 


Para calcular el indice hacen falta una serie de medidas anteriores: 


e Mt = numero de mddulos en la version actual. 

e Fm = numero de modulos en la version actual que han sido 
modificados. 

e Fa = numero de moddulos en la version actual que han sido afadidos. 

e Fe = numero de moddulos de la version anterior que se han eliminado 
en la version actual. 


A partir de estas, el IMS se calcula de la siguiente forma: 


_ [Mt-(Fa+Fm + Fe )| 
7 Mt 


IMS 


Métricas Orientadas a Objetos 


Las métricas OO se centran en métricas que se pueden aplicar a las 
caracteristicas de encapsulamiento, ocultamiento de informacion, herencia y 
técnicas de abstraccion de objetos que hagan unica a esa clase. 


Chidamber & Kemerer[footnote] proponen una familia de medidas para 
desarrollos orientados a objetos: 

Chidamber, S.R., D.P. y C.F.Kemerer, “Management Use of Metrics for 
Object-Oriented Software: An Exploratory Analysis”, IEEE Trans. 
Software Engineering. 


e Meétodos ponderados por clase 

e Profundidad arbol de herencia 

e Numero de descendientes 

e Acoplamiento entre clases 

e Respuesta para una clase 

e Carencia de cohesion en los métodos 


Métricas de Complejidad del Software 


Son todas las métricas de software que definen de una u otra forma la 
medicion de la complejidad; Tales como volumen, tamano, anidaciones, 
costo (estimacion), agregacion, configuracion, y flujo. Estas son los puntos 
criticos de la concepcion, viabilidad, andalisis, y disefio de software. 


Los 2 tipos de métrica para calcular la complejidad es: 


¢ Complejidad ciclomatica de McCabe] footnote] 

McCabe,T.J., y A.H. Watson, “Solftware Complexity”, Crosstalk. 
e Ciencia del Software de Halstead[footnote] 

Halstead, M., “Elements of Software Science”, Holland. 


Complejidad ciclomatica de McCabe 


La complejidad ciclomatica se basa en el recuento del numero de caminos 
logicos individuales contenidos en un programa. Para calcular la 
complejidad del software, Thomas McCabe utiliz6 la teoria y flujo de 
grafos. Para hallar la complejidad ciclomatica, el programa se representa 
como un grafo, y cada instruccion que contiene, un nodo del grafo. Las 
posibles vias de ejecucion a partir de una instrucci6n (nodo) se repesentan 
en el grafo como aristas. Por ejemplo, el cddigo que se muestra a 
continuacion con 2 sentencias selectivas anidadas genera el siguiente grafo: 


1 aif (condicion){ 2 if (condicion){ 3 A; B; } else ¢{ 
ace be oo Ge 


Si se realizase el grafo, se observaria que se encuentran 3 caminos posibles 
para llegar de la sentencia 1 a la sentencia 6: 


Camino 1 (si ambos IF’s son verdad): Sentencias 1, 2, 3, 6 
Camino 2 (si el primer IF es verdad y el segundo es falso): Sentencias 1, 4,6 
Camino 3 (si el primer IF es falso): Sentencias 1, 6 


Este programa tiene una complejidad ciclomatica de 3. 


La complejidad ciclomatica se puede calcular de otras maneras. Se puede 
utilizar la formula: 


v(G) =e-n+2 
donde e representa el numero de aristas y n el numero de nodos. 


Otra forma de calcular la complejidad ciclomatica consiste en aplicar la 
siguiente formula: 


v(G) = nimero de regiones cerradas en el grafo + 1 


Ejemplo de Calcular la Complejidad Ciclomatica 


Calcular la complejidad ciclomatica del método de ordenacion de la 
Burbuja siguiendo el siguiente cddigo: 


Public static void bubbleSort2 (Sequence S) { 
Position prec, Succ; 

Int nm = 'S,sizet); 

for Sint =O ar Si aes 

prec = S.first(); 

For uta =a) none eee 

Suce = S-arter(pree), 

if (valAtPos(prec) > valAtPos(succ) ) 
S.swapElements(prec, succ); 


ree = Succ: 


El codigo da como resultado el siguiente grafo: 


v(G)=12-10+2=4 


Complejidad ciclomatica = 4 


Ciencia del software de Halstead 


Durante el final de los afios 70 y principios de los 80, Maurice Halstead 
desarrolla un conjunto de métricas llamadas Halstead Software Science, 
métricas basadas en el calculo de palabras clave (reservadas) y variables. 


Su teoria esta basada en un simple cuenta (muy facil de automatizar) de 
operadores y operandos en un programa: 


e Los operadores son las palabras reservadas del lenguaje, tales como 
IF-THEN, READ, FOR.,...; los operadores aritméticos +, -, *,..... los de 
asignacion y los operadores logicos AND, EQUAL TO..... 

e Los operandos son las variables, literales y las constantes del 
programa. 


Halstead distingue entre el numero de operadores y operandos unicos y el 
numero total de operadores y operando. Por ejemplo, un programa puede 
tener un READ, siete asignaciones y un WRITE; por lo tanto tiene tres 
unicos operadores, pero nueve en total operadores, y de manera idéntica se 
procede con los operandos. Se utiliza la siguiente notacion: 


e ni - numero de operadores unicos que aparecen en un programa 
e N1 - numero total de ocurrencias de operadores 
e n2 - numero de operandos unicos que aparecen en un programa 
e N2 - numero total de ocurrencias de operandos 


Las métricas de la Ciencia del Software para cualquier programa escrito en 
cualquier lenguaje pueden ser derivadas de estas cuatro cuentas. A partir de 
ellas han sido elaboradas diferentes medidas para diversas propiedades de 
los programas, tales como longitud, volumen, etc... 


Por ejemplo, consideremos el siguiente trozo de programa: 
in (N24 


A=B*N;: 


System.out.println("El resultado es : " + A); 


, 

A partir de aqui se deduce: 

N2 = 6(N, 2, A, B, N, A) 

N1 = 6 (if, {}, system.out.println, =, *, <) 
n2 = 4 (N, A, B, 2) 

nl = 6 (if, {}, system.out.println, =, *, <) 


Halstead permite obtener una medida de la longitud, N, de un programa, 
que es calculada como: 


N=N1+N2 


N es una simple medida del tamafio de un programa. Cuanto mas grande 
sea el tamafio de N, mayor sera la dificultad para comprender el programa y 
mayor el esfuerzo para mantenerlo. N es una medida alternativa al simple 
conteo de lineas de codigo. Aunque es casi igual de facil de calcular, N es 
mas sensible a la complejidad que el contar el numero de lineas porque N 
no asume que todas las instrucciones son igual de facil o de dificil de 
entender. 


La medida de longitud, N, es usada en otra estimacion de tamafio de 
Halstead llamada volumen. Mientras que la longitud es una simple cuenta 
(o estimacion) del total de operadores y operandos, el volumen da un peso 
extra al numero de operadores y operandos unicos. Por ejemplo, si dos 
programas tienen la misma longitud N pero uno tiene mayor numero de 
operadores y operandos unicos, que naturalmente lo hacen mas dificil de 
entender y mantener, este tendra un mayor volumen. La formula es la 
siguiente: 


volumen V = N x log2(n) 


donden=—nl1+n2 


El esfuerzo es otra medida estudiada por Halstead que ofrece una medida 
del trabajo requerido para desarrollar un programa. Desde el punto de vista 
del mantenimiento, el esfuerzo se puede interpretar como una medida del 
trabajo requerido para comprender un software ya desarrollado. 


La formula es la siguiente: 


esfuerzo 


E=~ 
L 


donde el volumen V es dividido por el nivel del lenguaje L. Este indica si se 
esta utilizando un lenguaje de alto o bajo nivel. Por ejemplo, una simple 
llamada a un procedimiento podria tener un valor L de 1; el COBOL podria 
tener 0,1 y el ensamblador podria tener un L de 0,01. Asi pues el esfuerzo 
aumenta proporcionalmente con el volumen, pero decrece con la utilizacion 
de lenguajes de alto nivel. 


Atendiendo a varios estudios empiricos, el esfuerzo, E, es incluso una 
medida mejor de la entendibilidad (comprensién) que N. 


Ejemplo para calcular las medidas de Halstead 


Calcular las medidas de Halstead de longitud y esfuerzo para el siguiente 
algoritmo: 


a 

for (1=2)1<=n7 a) 
For (j=1;j<=1; j++) 
if (x[i] < xLj]) 
t 


aux = x[1i]; 


28) iii) 
x[J] = aux; 
} 
} 


Para realizar los calculos de longitud y el volumen, vamos a realizar antes 
otros calculos: 


Operadores: 
oe eee 
LorG;) = 2 
=> 5 


if- 1 


++ > 2 
[]- 4 


El numero total de operadores (n1) son 10 y la cantidad de operadores (N1) 
que hay son 23. 


Operandos: 


aux > 2 
El numero total de operandos (n2) son 5 y la cantidad total (N2) son 22. 
Por tanto, la longitud es 
N=N1+N2 
N=23-+22=45 
El volumen es 
V = Nx log2(n) 


V = 45 x log? (10+5)= 175.8 


Métricas Orientadas a Objetos 


Las métricas orientadas a objetos se centran en métricas que se pueden 
aplicar a las caracteristicas de encapsulamiento, ocultamiento de 
informacion, herencia y técnicas de abstracci6n de objetos que hagan unica 
a esa Clase. 


Chidamber & Kemerer[footnote] proponen una familia de medidas para 
desarrollos orientados a objetos: 

Chidamber, S.R., D.P. y C.F.Kemerer, “Management Use of Metrics for 
Object-Oriented Software: An Exploratory Analysis”, IEEE Trans. 
Software Engineering. 


e Meétodos ponderados por clase (MPC): Tamafio y complejidad 

e Profundidad arbol de herencia (PAH): Tamanio 

e Numero de descendientes (NDD): Tamafio, acoplamiento y cohesion 
e Acoplamiento entre clases (ACO): Acoplamiento 

e Respuesta para una clase (RPC): Comunicacién y complejidad 

e Carencia de cohesion en los métodos (CCM): Cohesion interna 


Estas métricas, en lineas generales, permiten averiguar cuan bien estan 
definidas las clases y el sistema, lo cual tiene un impacto directo en la 
mantenibilidad del mismo, tanto por la comprension de lo desarrollado 
como por la dificultad de modificarlo con éxito. 


Métodos ponderados por clase 


Los métodos ponderados por clase[footnote] asumen que n métodos de 
complejidad c1,c2,...cn se definen para la clase C. La métrica de 
complejidad especifica que se eligid debe normalizarse de manera que la 
complejidad nominal para un método toma un valor de 10. MPC = 
sumatorio de ci para cada i=1 hasta n. 

Weighted methods per class (WMC) 


El numero de métodos y su complejidad son indicadores razonables de la 
cantidad de esfuerzo requerido para implementar y verificar una clase. 
Cuanto mayor sea el numero de métodos, mas complejo es el arbol de 


herencia. A medida que crece el nimero de métodos para una clase dada, 
mas probable es que vuelvan mas y mas especificos de la aplicaci6n, asi 
que se limita el potencial de reutilizaci6n. El MPC debe mantenerse bajo. 


Profundidad del arbol de herencia 


Todos los autores hacen notar la necesidad de medir las estructuras 
hereditarias en términos de profundidad o de densidad de nodos. Dichas 
jerarquias pueden medirse como la profundidad de cada clase dentro de su 
jerarquia, es decir, la longitud maxima desde el nodo que representa la clase 
hasta la raiz del arbol. 


A medida que crece el valor del PAH, es mas probable que las clases de 
niveles inferiores hereden muchos métodos. Esto da lugar a posibles 
dificultades cuando se intenta predecir el comportamiento de una clase y 
por lo tanto, mantenerla. Una jerarquia profunda lleva también a una mayor 
complejidad de disefio. Por otro lado, los valores grandes de PAH implican 
que se pueden reutilizar muchos métodos, lo que debe ser considerado 
como un elemento a favor de la mantenibilidad. 


Si tenemos el siguiente arbol: 


El valor del PAH para la jerarquia de las clases mostradas es de 4. 


Numero de descendientes 


Las subclases que son inmediatamente subordinadas a una clase de la 
jerarquia de clases se denominan sus descendientes. A medida que crece el 
numero de descendientes[footnote] NDD, se incrementa la reutilizacion, 
pero también implica que la abstracci6n representada por la clase 
predecesora se ve diluida. Esto dificulta el mantenimiento, ya que existe la 
posibilidad de que algunos de los descendientes no sean realmente 
miembros propios de la clase. 

Number of children (NOC) 


Acoplamiento entre clases 


Para una clase determinada el acoplamiento entre clases[ footnote] se define 
como el numero de otras clases con las cuales esta “acoplada”. Es por lo 
tanto una medida del fan-out, esto es, del numero de colaboradores (clases 
que se utilizan desde esa). Sistemas en los cuales una clase tiene un alto 
ACO y todas las demas tienen valores proximos a cero indican una 
estructura no orientada a objetos, con una clase principal dirigente. Por el 
contrario, la existencia de muchas clases con un ACO grande indica que el 
disenador ha afinado demasiado la “granularidad” del sistema. Ninguna de 
las dos situaciones es deseable para la mantenibilidad: la primera situacién 
hace complejo el mantenimiento de la clase con gran ACO y en la segunda 
situacion la complejidad para entender el flujo del programa complica el 
mantenimiento. 

Coupling between objects (CBO) 


Respuesta para una clase 


La respuesta para una clase (RPC)[footnote] mide tanto la comunicacion 
interna como la externa. Esta métrica captura el tamafo del conjunto de 
respuesta para una clase. Este conjunto de respuesta para una clase consiste 
en todos los métodos llamados por los métodos locales. Definimos RPC 
como el numero de métodos locales mas el numero de métodos Ilamados 
por los métodos locales. 

Response for class (RFC) 


Otra definici6n que podemos dar del conjunto de respuesta de una clase es 
la siguiente: “conjunto de métodos que pueden ser ejecutados 
potencialmente en respuesta a un mensaje recibido por un objeto de esa 
clase”. La RPC se definiria como el nimero de métodos existentes en el 
conjunto de respuesta. 


Hay que precisar que no se discrimina entre dos mensajes enviados a un 
mismo método pero desde diferentes partes de la clase. 


A medida que el RPC crece, el esfuerzo necesario para las verificaciones y 
pruebas crece, ya que la complejidad global de diseno de la clase crece 
también. 


Carencia de cohesion en los métodos 


La cohesion de una clase esta caracterizada por cuan estrechamente estan 
relacionados los métodos locales a las instancias de variables locales en una 
clase. La carencia de cohexién en los métodos (CCM)([footnote] se define 
como el numero de conjuntos disjuntos de métodos locales. 

Lack of cohesion in methods (LCOM) 


Unos valores elevados para CCM implican que la clase podria disenarse 
mejor descomponiéndola en dos o mas clases distintas. Aun cuando existen 
casos en que es justificable un valor elevado de CCM, es deseable mantener 
un elevado grado de cohesion, esto es, mantener un valor bajo para CCM. 


Métricas de la Calidad del Diseho Orientado a Objetos del Software 


La calidad del software puede ser entendida como el grado con el cual el 
usuario percibe que el software satisface sus expectativas. El tipo y nimero 
de actividades de garantia de calidad que es necesario adoptar en un 
proyecto o en una organizacion depende del tamano y complejidad de los 
productos software que se estén desarrollando. También influyen otros 
factores, como pueden ser el tipo de proceso de desarrollo de software o los 
métodos y herramientas utilizados, la estructura organizativa de la 
organizacion, la motivacion del personal, entre otros. Seguin el modelo de 
calidad ISO 9126, la calidad de un proceso contribuye a mejorar la calidad 
del producto, y, a su vez, la calidad del producto contribuye a mejorar la 
calidad en uso. La finalidad de la calidad en uso es medir la efectividad, 
productividad, seguridad y la satisfaccion de los usuarios (pertenecientes a 
perfiles determinados) que interactiian con el producto en escenarios 
especificos de uso. 


Robert Martin[footnote], en 1995, estableci6 un conjunto de métricas para 
medir la calidad de los disefos orientados a objetos. En términos de la 
interdependencia entre los subsistemas del disefio (paquetes en Java) 
partiendo de la base de que, aunque las interrelaciones son necesarias, los 
disenos con subsistemas fuertemente interrelacionados son muy rigidos, 
poco reutilizables y dificiles de mantener. Martin propone una medida para 
cada paquete, que llama inestabilidad (1): 

Martin, R. (1995) OO Design Quality Metrics: An Analysis of 
Dependencies. Report on Object Analysis&Design, vol. 2 (3). 

Equation: 


I- Ce 
~~ Ca+Ce 


Donde Ce es el nimero de clases dentro del paquete que dependen de otras 
clases de otros paquetes; Ca es el numero de clases de otros paquetes que 
tienen una dependencia con clases del paquete. 


La medida de inestabilidad esta entre 0 y 1. Cuando es 1, significa que 
ningun paquete depende del paquete que se esta midiendo, y por el 


contrario este paquete si depende de otros paquetes, siendo un paquete 
inestable: es no responsable y dependiente. La falta de paquetes que 
dependan de él no le ofrece razones para no cambiar, y los paquetes de los 
que depende pueden darle amplias razones para cambiar. 


Por el contrario, cuando la inestabilidad es nula, I=0, significa que uno o 
varios paquetes dependen de él, pero él no depende de nadie. Es 
responsable e independiente, convirtiéndose en un paquete completamente 
estable. Los médulos que dependen de él hacen fuerza para que sea dificil 
de cambiar, y como él no depende de otros paquetes no se ve forzado a 
cambiar. 


El principio de las dependencias estables dice que la métrica I de un 
paquete debe ser mayor que las métricas I de los paquetes de los que él 
depende, esto es la métrica I debe decrecer en la direccién de la 
dependencia. 


Se debe tener presente que no es deseable que todos los paquetes sean 
completamente estables, porque el sistema no podria modificarse. 


Ejemplo de calculo de la estabilidad 


En el ejemplo de la figura siguiente, se va a proceder a calcular la 
estabilidad del paquete que se encuentra en el centro de la figura. Se tienen 
4 clases externas al paquete que tienen dependencia de las clases internas 
(la clase A se deriva de la clase e1, la clase B contiene objetos de la clase 2, 
la clase C contiene objetos de la clase 2, y la clase E se deriva de la clase 1), 
por lo tanto, se tiene que Ca=4. 


Por otra parte se tiene que existen 3 relaciones de las clases interiores del 
paquete que tienen como destino clases exteriores al paquete, es decir, 
existen 3 dependencias de las clases interiores del paquete con clases 
exteriores (la clase 1 contiene objetos de la clase G, la clase 1 se deriva de 
la clase H, y la clase 2 tiene una relacion de asociacion con la clase I), por 
lo tanto Ce=3. Asi, I=3/7. Por tanto, esta casi en el limite de la 
inestabilidad. 


Técnica del Indice de mantenibilidad 
El indice de Mantenibilidad (IM) mide la facilidad de mantenimiento del producto considerado. 
Toda accion de mantenimiento puede dividirse en 3 tareas: 


¢ comprension de los cambios que deben hacerse 
e realizacién de las modificaciones necesarias 
e pruebas de los cambios realizados 


Welker[footnote], en 1995, definio el concepto de indice de mantenibilidad IM para intentar cuantificar la 
mantenibilidad de un sistema. Este concepto ha sido perfeccionado por multiples autores a lo largo de estos afios. 
Welker, K.D. y Oman, P.W. (1995) Software Maintainability Metrics Models in Practice. Crosstalk, Journal of 
Defense Software Engineering 8, 11 (November/December 1995), pp. 19-23. 


El IM de un conjunto de programas mas basico es un polinomio de la siguiente forma: 

IM = 171 - 5.2 * In(aveV) - 0.23 * aveV(g’) - 16.2 * In (aveLOC) + 50 * sin (sqrt (2.4 * perCN 
Donde aveV es la media del volumen V por médulo segtin Halstead, ave V(g’) es la media de la complejidad 
cilclomatica por médulo, aveLOC es la media del numero de lineas de cddigo por médulo y perCM es la media 


porcentual de lineas de codigo comentadas. 


Cuanto mayor sea el IM, mayor mantenibilidad tendra el sistema. 


Métricas relacionadas con el proceso 


Las métricas del proceso se recopilan de todos los proyectos y durante un 
largo periodo de tiempo. Su intento es proporcionar indicadores que lleven 
a mejoras de los procesos de software a largo plazo. Un indicador es una 
métrica o una combinacion de métricas que proporcionan una vision 
profunda del proceso del software, del proyecto de software o del producto 
en Si. 


La medicion del proceso implica las mediciones de las actividades 
relacionadas con el software siendo algunos de sus atributos tipicos el 
esfuerzo, el coste y los defectos encontrados. Las métricas permiten tener 
una vision profunda del proceso de software que ayudara a tomar decisiones 
mas fundamentadas, ayudan a analizar el trabajo desarrollado, conocer si se 
ha mejorado o no con respecto a proyectos anteriores, ayudan a detectar 
areas con problemas para poder remediarlos a tiempo y a realizar mejores 
estimaciones. 


Para mejorar un proceso se deben medir los atributos del mismo, desarrollar 
métricas de acuerdo a estos atributos y utilizarlas para proporcionar 
indicadores que conduzcan la mejora del proceso. Los errores detectados 
antes de la entrega del software, la productividad, recursos y tiempo 
consumido y ajuste con la planificaci6n son algunos de los resultados que 
pueden medirse en el proceso, asi como las tareas especificas de la 
ingenieria del software. 


Las métricas del proceso se caracterizan por: 


e El control y ejecucion del proyecto. 

e Medicion de tiempos del analisis, diseho, implementacion, 
implantacion y postimplantacion. 

e Medicion de las pruebas (errores, cubrimiento, resultado en numero de 
defectos y numero de éxito). 

e Medicion de la transformacion o evolucion del producto. 


Estas métricas evaluan el proceso de fabricaci6n del producto 
correspondiente. Algunos ejemplo clasicos de este tipo de métricas son el 
tiempo de desarrollo del producto, el esfuerzo que conlleva dicho 


desarrollo, el nimero y tipo de recursos empleados (personas, 
maquinas,...), el coste del proceso, etc. 


El tiempo requerido para completar un proceso en particular (tiempo total 
del proyecto, por ingeniero, por actividad, etc) es un indicador de la 
mantenibilidad del sistema a tener en cuenta. Aunque no se puede 
generalizar, cuanto mayor es el tiempo total y por ingeniero para desarrollar 
un sistema mayor sera su complejidad y por lo tanto mas dificil sera de 
mantener. 


De la misma manera, cuantos mayores sean los costes requeridos para un 
proceso en particular (esfuerzo en personas-dia, costes de viajes, recursos 
de hardware), menor sera la mantenibilidad del sistema. 


Ademias, de estas, el numero de defectos descubiertos durante la fase de 
pruebas y las métricas relacionadas. 


Defectos descubiertos durante las pruebas 


El numero de defectos encontrados durante la fase de pruebas una vez que 
el codigo esta integrado esta correlacionado positivamente con el numero 
de defectos del software que se encontraran durante la explotacion del 
mismo. 


Un gran numero de defectos durante las pruebas indica que durante la fase 
de desarrollo se han cometido muchos errores, y, salvo un gran esfuerzo en 
la fase de pruebas, parte de estos errores se arrastraran hasta que el sistema 
esté en explotacion. 


Métricas relacionadas con las reparaciones de procesos 


Una posible manera de medir la mantenibilidad de un software durante su 
proceso de construccién es medir la frecuencia de fallos debidos a efectos 
laterales producidos después de una modificacion (X): 


_1-A 
iB 


xX 


siendo A el numero de fallos debidos a efectos laterales detectados y 
corregidos y B= numero total de fallos corregidos. 


Cuanto mayor sea X es predecible que mas dificil sera de mantener en el 
futuro el sistema. 


